Переходим к плану лекции. Обозначьте структуру — сегодня охватываем путь от базового понятия процесса до потоков. Студенты должны понимать логику: от простого к сложному.
Введение задаёт мотивацию. Подчеркните: без понимания процессов невозможно разбираться ни в планировании, ни в синхронизации, ни в памяти. Это фундамент всей архитектуры ОС.
Начинаем с определения процесса. Приведите пример: браузер, текстовый редактор — каждый запущенный экземпляр программы является процессом. Акцент: процесс — это не просто код, а код + данные + стек + ресурсы.
Ключевое сравнение. Аналогия: программа — это рецепт на бумаге, процесс — повар, который готовит по этому рецепту. Один рецепт могут использовать несколько поваров одновременно.
Переходим к внутреннему устройству. PCB — «паспорт» процесса, без него ОС не может управлять процессом. Подчеркните: PCB создаётся при рождении процесса и уничтожается при смерти.
Разбираем содержимое PCB по частям. PID — это как паспортный номер, состояние — «где сейчас находится» процесс, регистры — для возобновления выполнения, память — границы адресного пространства.
Продолжение PCB. Учётные данные определяют права доступа, I/O-информация — открытые файлы и устройства, статистика нужна для учёта ресурсов. Всё это хранится в одной структуре.
Таблица процессов — это коллекция всех PCB. Подчеркните: когда мы говорим «ОС управляет процессами», она работает именно через таблицу процессов. В Linux её можно увидеть через /proc.
Сравните подходы к организации таблицы. Массив — проще, но ограничен; связный список — гибче; хеш-таблица — быстрый поиск по PID; дерево — отражает иерархию «родитель-потомок». В реальных ОС используется комбинация.
Начинаем жизненный цикл процесса. Подчеркните: процесс не существует в одном состоянии — он постоянно переходит между состояниями. Это как разгрузка в аэропорту: регистрация → ожидание → полёт.
Два оставшихся состояния. Ожидание — процесс добровольно отдаёт CPU (ждёт I/O). Завершение — процесс выполнил задачу или убит, ресурсы освобождаются.
Диаграмма — визуальное отображение модели состояний. Обратите внимание студентов на направления стрелок. Не все переходы возможны: например, нельзя перейти напрямую из Waiting в Running.
Таблица переходов — формализация диаграммы. Акцент: переход Running → Ready происходит при вытеснении, а Running → Waiting — по инициативе самого процесса. Это разные механизмы.
Очереди — механизм, через который ОС реализует состояния. Каждый процесс «путешествует» по очередям на протяжении жизни. Подчеркните связь с предыдущей темой: состояние процесса = очередь, в которой он находится.
Три основных типа очередей. Ready Queue — самая важная, из неё планировщик берёт процессы. Device Queues привязаны к конкретным устройствам. Процесс может одновременно находиться в нескольких очередях.
Сравниваем реализации. FIFO — база, Round Robin — основа многозадачности, приоритетная — для систем реального времени, многоуровневая — наиболее гибкая, используется в современных ОС.
Начинаем алгоритмы планирования. FCFS — самый простой, но неэффективный. Обязательно объясните «эффект конвоя» на примере: один длинный процесс блокирует множество коротких.
SJF теоретически оптимален, но на практике неприменим — ОС не знает заранее длительность процесса. Объясните подход оценки: экспоненциальное среднее предыдущих «порций» выполнения.
Наглядное сравнение двух базовых алгоритмов. FCFS проще, но страдает эффектом конвоя. SJF лучше по метрикам, но практическая реализация затруднена. Оба могут приводить к несправедливости.
Round Robin — самый распространённый алгоритм для интерактивных систем. Ключевой параметр — квант времени: обычно 10–100 мс. Слишком малый квант — потери на переключение, слишком большой — снижение отзывчивости.
Приоритетное планирование гибко, но создаёт проблему голодания. Решение — старение (aging): чем дольше процесс ждёт, тем выше его приоритет. В Linux используется вариант — Completely Fair Scheduler.
Сводная таблица — резюме по алгоритмам. RR — лучший баланс справедливости и сложности. В реальных ОС используются гибридные подходы: многоуровневые очереди с обратной связью.
Переключение контекста — скрытая стоимость многозадачности. Подчеркните: во время переключения CPU не выполняет полезную работу. Цель — минимизировать накладные расходы.
Перечисляем компоненты контекста. Регистры и PC — минимальный набор для возобновления, остальное — для корректной работы с памятью и ресурсами. Всё это хранится в PCB.
Пошаговый процесс переключения. Шаги 1–3 — «заморозка» текущего процесса, шаги 4–6 — «разморозка» нового. Обратите внимание: шаг 3 и 4 связаны с очередями — планировщик выбирает из ready queue.
Накладные расходы — практический аспект. Типичное время: 1–10 мкс. На многоядерных системах меньше. Аппаратная поддержка (несколько наборов регистров) значительно снижает overhead.
Переходим к IPC — как процессы взаимодействуют. Проблема: процессы изолированы, но часто нуждаются в обмене данными. IPC — набор механизмов для координации и обмена.
Четыре основных механизма. Сигналы и каналы — простые, для базовых сценариев. Очереди сообщений и разделяемая память — для интенсивного обмена. Разделяемая память — самая быстрая, но требует синхронизации.
Сравнительная таблица помогает выбрать механизм под задачу. Для простых уведомлений — сигналы, для потоковых данных — каналы, для структурированного обмена — очереди, для максимальной скорости — разделяемая память.
Потоки — «легковесные» процессы. Ключевая идея: потоки одного процесса разделяют адресное пространство, что делает создание и переключение намного дешевле. Но возникает проблема синхронизации.
Ключевое сравнение. Процесс — тяжеловесный, изолированный, дорого стоит создание. Поток — лёгкий, разделяет память с другими потоками процесса, создаётся быстро. Выбор между процессами и потоками зависит от задачи.
Преимущества многопоточности — почему потоки так важны. Параллелизм на многоядерных CPU, отзывчивость UI, экономия памяти. Но добавляется сложность: гонки данных, deadlock'и.
Две базовые модели. Пользовательские потоки — быстрые, но блокировка одного блокирует весь процесс. Потоки ядра — надёжнее, но медленнее. Каждая модель — компромисс.
Гибридная модель — лучшее из двух миров. N пользовательских потоков мультиплексируются на M потоков ядра (N:M). Используется в Linux (NPTL) и Windows. Это индустриальный стандарт.
Подводим итоги. PCB — паспорт процесса, состояния — жизненный цикл, очереди — механизм управления, планирование — стратегия распределения CPU. Всё взаимосвязано.
Ключевые выводы на два столбца. Левый — управление и планирование, правый — взаимодействие и перспективы. Подчеркните: эти темы — основа для следующих лекций по синхронизации и памяти.
Вопросы для самопроверки. Порекомендуйте студентам ответить на каждый вопрос письменно — это лучший способ закрепить материал. Обратите внимание на вопрос 10 — «эффект конвоя» часто встречается на экзаменах.
Рекомендованная литература. Таненбаум — лучший учебник для данного курса, Silberschatz («Динозавр») — классика. Love — для тех, кто хочет разобраться в реализации Linux. Все книги есть в библиотеке.